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(54) Methods and apparatus for providing a broker appiication server 



(57) A broker application server forfacililatmg com- 
munication between one or more senders and one or 
more receivers over a digital packet network. Each re- 
ceiver receives data in a preferred format. Information 
identifying the preferred data format of each receiver is 
stored in a database in the broker application server. 
The broker application sen/er receives digital packets 
addressed to a receivef. it extracts data and address 
information from the packet and optionally decrypts the 
data. It examines the data to identify the data format. If 
the data is in the preferred format of the addressed re- 
ceiver, the broker application server optionally encrypls 
the data, formats it into a packet, and transmits it to the 
appropriate receiver. If the data is not in the preferred 
format of the addressed receiver, the data is transcoded 
into a common or raw data format and further transcod- 
ed into the preferred data format of the addressed re- 
ceiver before being optionally encrypted, formatted into 
a digital packet, and transmitted to the addressed re- 
ceiver. 
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Description 

Field of the Invention 

The present invention relates generally to brokering 
services within computer networks. More particularly, 
the invention relates to methods and apparatus for pass- 
ing data between the Internet and a computer or periph- 
eral and for translating data received from the Internet 
to a user's preferred format. 

Bacltground of the Invention 

Recently, the Internet has grown from being a 
somewhat esoteric and restricted community to being 
the meeting ground of vast numbers o1 users. Large 
numbers of new users have obtained Internet access, 
and many new content providers are now seeking to 
provide access to their products or sen/ices via the In- 
ternet. EHorts to make Ihe Internet accessible to users 
who did not wish to go to the expense of purchasing a 
computer have been highly publicized. Plans have been 
announced for the marketing of low cost terminals with 
reduced leature sets which could provide access to an 
Internet provider, and such products were demonstrated 
and shipped. The access provided by such terminals is 
more limited compared to that utilizing a full function 
computer, but they are much less expensive than a more 
genera! purpose computer which might provide features 
which a user did not need or want. 

Complicating efforts to provide such terminals, and 
even complicating the lives of Internet users with large 
and powerful computers, has been the proliferation of 
ever more elaborate Internet content. Internet content 
now routinely may include, for example, pictures, sound, 
animated tittes, streaming audio, streaming video, and 
movies, with newfeatures being developed almost daily. 
These content features may present problems for sim- 
ple terminals, and they may present a processing bur- 
den to fuller function computers and their users as well. 
This is particularly true with respect to beginning com- 
puter users. As an example, in order to display many 
sophisticated content leatures, a user must download 
and install what are called "plug-ins". Plug-ins may be 
defined as special application programs activated by a 
user's Internet browser, which display whatever special 
features the plug-in is designed to display, such as 
Quicktime® movies, RealAudio®, VIVO® streaming 
video, and so on. These plug-ins are often quite large 
in terms of the memory required to store them, and al- 
though they are often provided to the user free of 
charge, they nevertheless represent a significant invest- 
ment of time for downloading, installation, and mainte- 
nance, as weil as requiring a significant allocation of disk 
memory. Such browser related issues will be recognized 
as exemplary. Other examples are email attachments 
which require conversion or encoded files, such as 
MIME files, which need to be unencoded. Such proc- 



esses should ideally be transparent to the user. 

It would represent a significant improvement over 
the prcScnt state of the art if a broker server could re- 
ceive information from a client about the client's pre- 
5 ferred viewing protocols and translate received packets 
so Uiat they could be conveniently viewed by the client 
without the client having to undertake the downbading 
of a plug-in or the like. Such a capability might well be 
critical for the support of an Intemet-onty terminal, but 
10 would also represent a significant advantage even 
where the client was a top-end multimedia computer 
system. The user of a powerful multimedia system 
would, by downloading and installingail necessary plug- 
ins, be able to display all Internet content features, but 
at a significant commitment of time and disk space 
which he or she might wish to avoid. Further, a signifi- 
cant barrier to further growth of Internet commerce is 
that the interchange of all forms of information and data 
must become easier to attract a broader base of less 
^0 computer literate users. A broker server which could re- 
move the necessity of dealing with plug-ins would pro- 
vide significant advantages to all classes of users. 

A broker server with translation capabilities could 
also provide individual users with the capability of trans- 
25 iatlng between different tormats: for exarnpie, audio in- 
formation from WAV to AU, visual information from JPG 
to GIR and so on. 

In addition to trans lationot Internet content features 
which are commonly presently used, there exists a po- 
30 tential for translating different information formats which 
are not comnrionly thought of as subject to translation. 
For example, a broker server could provide speech-to- 
lext or text-to-speech translation capabilities. Imple- 
mentation of such a capabiiity might require significant 
55 computing power and be more economically performed 
by a server, rather than by a client computer operated 
by an end user Addition at uses are translation of video 
to still images, TIF documents, such as facsimile imag- 
es, to ASCII by using optical character recognition 
40 ("OCR") within the broker, for example, and MIDI to syn- 
thesized music. The above features are provided as ex- 
emplary of areas in which improved operation is desir- 
able. These and other features would give a broker sen/- 
er significant new capabilities which no Internet provider 
^5 presently provides. These features wouid provide great 
flexibility to users, allowing users to employ their pre- 
ferred information formats, and to communicate with 
other users and content providers who use entirely dif- 
ferent and incompatible formats. 
so Format conversion capability presently exists in 
personal computers, usually as non-real-time format 
conversion programs. For example, a VOC file can be 
converted to a WAV file. This conversion typically does 
not happen in real time and is not transparent to the user. 
55 Other converters exist which are capable of performing 
a conversion from one format to another as opposed to 
providing a flexible conversion facility based on user 
preferences. 
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There exists, therefore, a need in the art for a broker 
server which can provide a facility for conversion be- 
tween data formats in real time, transparent 1o the user, 
and flexibly based on inputs from the user. 

Summary oi the Invention 

A Broker Application Server, or BAS, according to 
one aspect of the present invention, receives an input 
from a user identifying the user's preferred data formal 
or formats. The BAS receives digital packets from a 
sen/en extracts data from the packets, performs an op- 
tional security encryption or decryption step, and exam- 
ines the data to determine if the data is in the user's pre- 
ferred format. While it is presently preferred that this 
conversion proceed on a packet by packet basis as de- 
scribed more fully below, it will be recognized that for 
some formats the BAS will collect all or some packets 
to be converted before conversion is done. If the data is 
in the user's preferred format, the BAS may perform an 
optionai security encryption or decryption step, formats 
the data into packets, and then transmits it to the user. 
If the data is not in the user's preferred data format, the 
B.AS transcodes the data into a common format, and 
Jhen transcodes the data from a common format to the 
user's preferred format. Alternaiively, the BAS may in 
appropriate circumstances transcode data direcily into 
the user's preferred formal, in the event the BAS cannot 
transcode data to the user's preferred format, preferably 
it will transcode the data to a second format which while 
not preferred is still understandable or compatible. The 
BAS then performs an optional security encryption or 
decryption step, formats the data into packets, and 
transmits it to the user 

. An alternative aspect of the present invention also 
incfudes a database of preferred formats for customers 
or. alternatively, storage to hold preferred format infor- 
mation derived at the establishment of a connection be- 
tween the customer and the BAS. A secondary format 
may also be identified and stored. In this embodiment 
of the present invention, after each data packet has 
been transcoded to a common format, the BAS iooks up 
the client to which the packet is addressed to find the 
client's preferred data format, as well as the secondary 
format if necessary. The BAS then transcodes the data 
to that client's preferred format, optionally encrypts the 
data, formats the data into a packet, and transmits the 
data to the user A BAS according to this aspect of the 
present invention can accommodate a substantial 
number of users, the number being only limited by the 
constraints of the network hardware providing the cctfi- 
neclion and by the hardware chosen (or the BAS. A sys- 
tem in accordance with the present invention can be 
flexibly expanded as may be required. 

A more complete understanding of the present in- 
vention, as well as further features and advantages of 
the invention, will be apparent from the following De- 
tailed Description and the accompanying drawings. 



Brief Description of the Drawings 

Fig. 1 is a functional block diagram representing a 
Broker Application Server ("BAS") according to one 
5 aspect of the present invention; 

Fig. 2 is a functional block diagram representing a 
BAS according to another aspect of the preser>t in- 
vention; 

Fig. 3 is a flowchart of a process for translating data 
to a user's preferred format in accordance with the 
present invention; 

Fig. 4 is a hardware diagram illustrating hardware 
components of a BAS according to the teachings of 
the present invention; and 
Fig. 5 is a network diagram illustrating a network 
environment in which a BAS according to the 
present invention can advantageously operate. 

Detailed Descrlptten 

Fig. 1 1llustrates a BAS 1 0 which can advantageous- 
ly serve as an intermediary between a sender 12 and a 
receiver 14. Sender 12 can be an individual computer^ 
a network node, a Point of Presence of an Internet Serv- 
ice Provider or any other device which transmits digi- 
tized packets. Receiver 14 is typically a client computer 
operated by a user who subscribes to a service of which 
BAS 10 is a component. The receiver 14 may suitably 
be a general purpose personal computer or an Internet 
or web terminal with more limited functionality. While a 
single sender 12 and receiver 14 are shown in Fig. 1 for 
ease of iilustration, it will be recognized that a large 
number of senders and receivers wiH typically be served 
by the BAS 10. By way of example, the sender 12 and 
receiver 14 may be connected to BAS 10 utilizing mo- 
dems and analog or digital transmission via telephone 
lines or any other suitable network connections. While 
it is presently preferred that a sender will send a file 
which is Iransmitted and received in compatible format 
as described herein, it will also be recognized that an 
incompatible block of data may be received by a user 
who will send that bbckto BAS 1 0 and then receive back 
the preferred format so that a single user is both the 
sender and the receiver 

When a connection is established between the BAS 
10 and the receiver 1 4, control is passed to a preferred 
data format identifier 102 and the preferred data format 
of the receiver 14 is recognized and stored in a memory 
103 by the BAS 1 0. A secondary or additional data for- 
mats may also be stored. Sender 12 transmits packets 
to BAS 10, each packet being addressed to the receiver 
14. When BAS 10 receives a packet, control is first 
passed to depacketizer 1 04. The data is extracted from 
the packet and the address information stored in the 
packet is examined. Control is tUen passed to decrypts r 
108 and the data is decrypted if it was received in en- 
crypted form. Control is then passed to data format iden- 
tifier 110 and the data format is identified. Control is then 
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passed to format comparator 1 1 2, and the identified for- 
mat for the data Is examined to determine if it is in the 
preferred data format of ihe receiver 14. H She data is in 
the preferred format of receiver 14, control is passed di- 
rectly to encrypter 1 20. If the data Is not in the preferred 
format of receiver 14, control is transferred to a first 
Iranscoder 116 and the data is transcoded into a com- 
mon or generic format. The data now in a common for- 
mat is then further transcoded in a second transcoder 
118 Into the preferred format of the receiver 14. While 
Ihe above described conversion arrangement is pres- 
ently preferred, it will be recognized that in appropriate 
circumstances a single transcoder may suffice to per- 
form the conversion to preferred format. For formats in 
which packet by packet conversion is not possible or de- 
sirable, all or some of the packets may be stored in a 
memory and then converted as a unit. For example, a 
frame of video will consist of muitlple packets which 
should be converted together 

Following conversion, control is \her\ transferred to 
encrypter 1 20 and the data Is optionally encrypted. The 
cJata is transferred to packetizer 1 22 and reformatted in- 
to a packet. The data is finally transmitted to ihe receiver 
14 and the user by transmitter 124. If the data does not 
need to be encrypted, block 120 is bypassed and the 
data is transferred directly to the packetizer 122. The 
foregoing data processing repeats for each packet ex- 
cept as addressed above where multiple packets are 
stored and translated together. 

Fig. 2 functionally illustrates a second BAS 20 ac- 
cording to a second embodiment of the present inven- 
tion. BAS 20 provides an interface between a sender 22 
and a plurality of receivers 24, 26, 28 and 30. For pur- 
poses of simplicity, only a single sender and four receiv- 
ers are shown; however, depending on the design of 
BAS 20 a large number of both senders and receivers 
may be accommodated. 

vviitrsjl edui I KJi Lilt::; i tfcurv-uia czi ilj ovj ni ol 

establishes a connection with the BAS 20. control is 
transferred to a fonmat preference identifier 201 and a 
preference database 202 is established, storing the pre- 
ferred data format of each of receivers 24, 26, 28 and 
30 . When the BAS 20 receives a pac ket t rom the sonde r 
22, control processing starts at depacketizer 203, and 
depacketizalion occurs. That is, the data is extracted 
and evaluated to determine if it is encrypted and the 
packet address is read, if the packet is encrypted, con- 
trol is transferred to decryption circuitry or decrypter 206 
and the packet is decrypted if it was received in an en- 
crypted format. Control is then transferred to data formal 
identifier 208 and the data format of the packet data is 
identified. Next, processing passes to a first transcoder 
210 and the packet data is transcoded into a common 
or generic format. The preferred data format of the ad- 
dressed receiver 24, 26, 28 or 30 is identified from the 
data obtained and stored by format preference identifier 
201. Finally, transcoding, encrypting and packetizing 
circuits 212, 214, 216 or 218 are alternatively employed 



depending on the destination address of the packet da- 
ta. The packet data Is then transcoded to the preferred 
format of the destination receiver, optionally encrypted, 
packetized, and routed to the appropriate receiver 24. 

6 26, 28, or 30 respectively. This process repeats for every 
new packet received except as addressed above where 
multiple packets are stored before transcoding. 

Preferably, each time one of the receivers 24, 26, 
28 or 30 estabiishes or breaks a connection, step 201 

10 is repeated to update the preferred data format informa- 
tion and alternative data formats as desired. Thus, data 
can be properly formatted for and routed to any of a 
number of destination receivers even where those re- 
ceivers have significantly different capabilities and tor- 

is mat preferences. 

Fig. 3 illustrates a process 300 according to the 
present invention which may suitably be carried out by 
a broker application server such as the BAS 1 0 illustrat- 
ed in Fig. 1 or the BAS 20 of Fig. 2. In step 302, a packet 

20 is received addressed to one of a plurality of receivers, 
In step 304, the packet is examined and the receiver 
address and data are extracted from the packet. Next, 
in step 306, the data is examined to determine if it is in 
encrypted format. If the data is in encrypted format, 

2^ processing proceeds to step 308 and the data is de- 
crypted. The process next proceeds to step 310. if the 
data is not in encrypted format, step 308 is bypassed. 

In step 310, the address is examined and the in- 
tended, destined or addressed receiver is identified. The 

30 preferred data format of the addressed receiver is de- 
termined. A database of preferred data formats of client 
receivers may be majntained, or, alternatively, each re- 
ceiver may identify its preferred data format to the BAS 
each time a connection is initiated. In step 312, the data 

35 is examined to determine if it Is in the preferred data 
format of the addressed receiver. If the data is not in the 
preferred format of the addressed receiver, the process 

common, or generic format. Next, the process continues 
40 with step 31 6, and the data is converted from the generic 
format to the preferred format of the addressed receiver. 
Step 31 8 follows. If the data is in the preferred format of 
the addressed receiver, step 318 immediately follows 
step 312 with steps 314 and 316 being bypassed. At 
step 318, it is determined whether the data was in en- 
crypted format when received. This may suitably be ac- 
compiished by storing the result of the determination 
made in step 306 and querying this information at step 
318. If the data was received in encrypted format, the 
50 process continues with step 320 and the data is encrypt- 
ed for transmission. If the data was not received In en- 
crypted format, block 320 is bypassed. 

In step 322, the data and address are formatted into 
a packet for transmission and the process continues 
55 with step 324. In step 324, the packet is transmitted to 
the addressed receiver. The process then loops backto 
step 302 and the process is repeated for the next packet. 
Fig. 4 is a hardware block diagram of a presently 
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preferred BAS 40 according to the teachings of the 
present invention. The BAS 40 includes a receiving unit 
or receiver 406 for receiving digital packets from one or 
more senders 52 shown as a single block in Fig. 4 for 
ease oi illustration, BAS 40 also includes a transmission 
unit Of transmitter 420 for transmitting digital packets to 
one or more receivers 54 shown as a single block in Fig. 
4 for ease of illustration. Each of the receivers 54 ac- 
commodates data in a preferred format. BAS 40 in- 
cludes a presently preferred data formal identification 
urtit 402 which receives information from each of receiv- 
ers 54 and identifies the preferred data format and ad- 
ditional data formats as desired of each particular re- 
ceiver 54. A database 404 receives and stores Informa- 
tion identifying the preferred data format for each of the 
receivers 54. Identification of the preferred data format 
and additional data formats as desired for each of the 
receivers 54 can be accomplished each time one of the 
receivers 54 connects to the BAS 40. Alternatively, this 
identification can be stored in a central registry, for ex- 
ample, the user database of an Internet Service Provid- 
er employing as part of its network a BAS such as the 
BAS 40, and updated periodically, with periodic updates 
being transmitted to the BAS 40. 

Upon receiving a digital packet from one of the 
senders 52, the receiving unit 406 transfers the packet 
to the packet analysis unit 408. Packet analysis unit 408 
extracts data and address tnformatbn from the packet 
and transfers the data to an encryption and decryption 
unit 410. The encryption/decryption unit 410 decrypts 
the data if it was received in encrypted form and trans- 
fers the data to a data analysis unit 412. The data anal- 
ysis unit 412 identifies the data format of the data and 
determines if the data is in the preferred format of its 
destined addressed receiver 54 by comparing the data 
format against the data format identification stored in da- 
tabase 404. If the data is in the preferred formal of the 
addressed receiver 54, the data analysis unit transfers 
the data to encryption/decryption unit 410. If the data is 
not in the preferred format, the data analysis unit 412 
transfers the data to a first transcoding unit 414. 

The first transcoding unit 414 reformats data re- 
ceived from data analysis unit 412 into a common, or 
"raw" data format, ft then transfers this raw data to a 
second transcoding unit 416. The second transcoding 
unit 41 6 formats the raw data to the preferred data for- 
mat or alternative acceptable format of the addressed 
receiver 64, in accordance with the preference data 
stored in the database 404, and transfers the data to the 
encryption/decryption unit 410. 

Upon receiving data from the data analysis unit 412 
or second transcoding unit 416, the encryption/decryp- 
tion unit 410 oplionaliy encrypts the data. The encryp- 
tion unit 410 encrypts the data if BAS 40 originally re- 
ceived ihe data encrypted. It will be recognized thai a 
preference to encrypt or decrypt data may be identified 
and stored by the preferred data format identification 
unit 402, or may be sent by sender 52. With such an 



approach, senders 52 and receivers 54 may employ dif- 
ferent formats of encryption while still maintaining an ap- 
propriate level of security. Upon completing its function, 
the encryption/decryption unit 410 transfers the data to 
5 packetization unit or packetrzer 418, where the data is 
formatted Into a digital packet. Finally, packetizer 418 
transfers the packet to the transmission unit 420, where 
it is transmitted lo the appropriate one of the receivers 
54. 

Fig. 5 illustrates a network 50 employing a Broker 
Application Server 60 according to the teachings of the 
present invention. Network 50 comprises a number of 
senders and receivers 64, 66. 68 and 70 which commu- 
nicate with the BAS 60 via Interr^et Access Points 72, 
74, 76, 78, and 80, BAS 60 can communicate with each 
sender and receiver on network 50 through the trans- 
mission of properly addressed digital packets. BAS 60 
need not be directly connected with any sender or re- 
ceiver in order to perform its functions. 

While the present invention is disclosed in the con- 
text of a presently preferred embodiment, it will be rec- 
ognized that a wide variety of implementations may be 
employed by persons of ordinary skill in the art consist- 
en! with Ihe above discussbn and the claims which fol- 
low below. 



Claims 

30 1. A method for mediating communication in a digital 
packet network comprising one or more senders 
(52) and one or more receivers (54), each of said 
senders transmitting digital packets, each of said 
packets containing data and address information, 

35 data in each of said packets having a particular data 
format, each of said receivers being operative to re- 
ceive data in one or more preferred data formats, 
said method comprising: 

40 receiving (406) a digital packet from a sender 

at a broker application server, 
extracting (408) data and address information 
from said packet utilizing the broker application 
server; 

45 identity ing (41 2) said data format of said data; 

if said data fomiat \s identical to said preferred 
data format of a receiver associated with the 
extracted data and address information, pack- 
etizing (418) said data and transmitting (420) 
so said data to said receiver; 

if said data format is not identical to said pre- 
ferred data formal of said receiver, transcoding 
(414^ 416) said data to satd preferred data for- 
mat of each of said receivers, packetizing (418) 
55 said data, and transmitting (420) said data to 

said receiver corresponding to said address in- 
format iCMi contained in said received packet. 
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2. The method of claim 1 further comprising the step 
of, for each of said receivers, identifying (402) and 
storing (404) said preferred data format in a mem- 
ory in the broker application server. 

3. The method of claim 2 further comprising the step 
of exam.ining (412) said data to determine whether 
it is encrypted and decrypting (410) sajd data if said 
data is encrypted. 

4. The method of claim 3 further comprising the step 
of encrypting (410) said data before packetizing 
(418) it for transmission (420) tosaid receiver, if said 
data was encrypted when received. 

5. The method of ciaim 3 further compfising the Step 
of determining (402) a preferred sncryplion format 
for said receiver and encrypting (410) said data in 
said preferred encryption formal before packetizing 
(418) it for transmission (420) tosaid receiver. 

6. A broker application server (40) lor facilitating com- 
munication between a plurality of senders (52) and 
a plurality of receivers (54) overa digital packet net- 
work, comprising: 

a preferred data format tdentiftcation unit (402) 
for receiving data identifying a preferred data 
lormat tor each of said receivers; 
a database (404) tor storing sakJ preferred data 
format identification for each of said receivers; 
a receiving unit (406) for receiving digital pack- 
ets from each of said senders; 
a packet analysis unit (408) for extracting data 
and address information from digital packets; 
a packetization unit (418) for formatting data 
and address information into a digital packet for 
tfansmission to one of sasd receivsfs; 
a transmission unit (420) for receiving a digital 
packet from said packetization unit and trans- 
mitting said digital packet to one of said receiv- 
ers; 

afirsl transcoding unit {41 4) for transcoding da- 
la into a common data format; 
a second transcoding (416) unit for receiving 
data from said first transcoding unit, transcod- 
ing said data to said preferred data format of 
one of said receivers to which said data is ad- 
dressed, and transferring said data to said 
packetization unit; and 

a da*a analysis unit (412) for identifying a data 
format o1 said data, said data analysis unit also 
being operative to read from said database said 
preferred data format of a receiver to which said 
data packet is addressed and transferring sajd 
datadirectlytosaid packetization unit if said da- 
ta is in said preferred format of said receiver or 
transferring said data to said first transcoding 



unit if said data is not in said preferred format 
of said receiver 

7. The broker application server of claim 6 further 
5 comprising an encryption and decryption unit (410) 

for receiving data from saki packet analysis unit, de- 
crypting data which is received encrypted, and 
transferring said decrypted data to said data analy- 
sis unit, sakJ encryption and decryption unit also be- 
10 ing operative to receive data from said data analysis 
unit or said second transcoding unit, encrypting said 
data when said data was extracted from an encrypt- 
ed packet, and transjerring said data to sakJ pack- 
etization unit. 

IS 

8. The apparatus at claim 6 wherein the data format 
identification uni! further operates to determine a 
preferred encryption format for an addressed re- 
ceiver. 

20 

9. The apparatus of claim 8 wherein the decryption 
and encryption unit operates to encrypt data in the 
preferred encryption format for the addressed re- 
ceiver 

25 

10. The method of claim 1 where the step of transcod- 
ing said data to said preferred data format compris- 
es first transcoding (414) said data to a common 
format and then transcoding (416) said data from 

30 the common format into the preferred format. 
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